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An Internet network protocol stack, 
along with special logic, is embedded in hard- 
ware° thereby enabling a modem to become 
Internet-ready. As a result, the modem of- 
floads much of the network protocol process- 
ing from the main CPU and improves the 
overall performance of the communication 
system. 
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' backgrounh of the in vention 
technical field 

The invention relates to combining a network stack with a modem core for use 
in both computer and non-computer applications. More particularly, the 
invention relates to an Intemet-aware modem which combines any number of 
point-to-point devices with the network protocols necessary to communicate 
on the internet., where these devices include various speed traditional 
modems from 2400 kbps to 55 kbps, ISDN modems, newer xDSL modems, 
and digital cellular modems. 

DESCRIPTION OF THE PRIOR ART 

Cbmputer modems were developed in a time when most connections were 
made to proprietary online services, interactive terminals, bulletin board 
20 sen/ices (BBSs), or corporate network systems. As such, it was necessary to 
implement connection protocols in software because there existed at the time 
a number of such protocols. These protocols included x-modem, y-modem. z- 
modem, kermit. and interactive character based interfaces. 
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Today, with popularity of the Internet, a vast majority of modems are now 
used exclusively to connect with ISP's, which in tum connect the user to the 
internet. Therefore, there is now a predominant set of connection protocols. 
Such protocols are used for most modem connections. Accordingly, there is a 
real need and advantage in designing a modem that is Internet-ready. , 

The connection protocols used by the Internet and their hierarchical 
relationship are shown in Fig. 1 . These protocols include TCP 10, IP 1 1. UDP 
13, and PPP 12. Optimizing a modem for use with the Internet offers many 
advantages including reduced transmission latency, reduced servicing 
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requirements, lower processing requirements from the system's CPU, and 
optimized transmission rates. 

Current computer systems treat a modem subsystem" as a serial device. A 
5 block diagram of an existing system is shown in Fig. 2. In suet, system, an 
internet application, such as a Web browser 21, is run in software 19 on the 
main CPU 22. This application, in turn calls upon the computer network stack 
23 which is also implemented in software. The network stack implements the 
TCP IP UDP and PPP protocols. Once the data have been processed, the 
0 resuiting packets are sent by the CPU via the computer bus 28 to a serial port 
interface 27 in the modem system 30. The modem system, for example a 
. modem card 18, is seen as a serial 1/0 device by the host processor. These 
devices usually accept data in byte quantities and place them in an outgoing 
FIFO 24 These FIFOs can be anywhere from 8 bytes to 64 bytes. The CPU 
5 normally writes a fixed number of bytes, then waits for the serial 1/0 dev.ce to 
•notify it that all the data have been sent and that it is ready to accept more 
data This notification is usually done via system interrupts. The packet data, 
aner 1. is written into the FIFO, is fed to the modem core 25 at the outgoing 
data rate and thence to the telephone line 29. , 

For received data, the modem first-places all Incoming packets into the input 
FIFO 26 The device can then be configured to interrupt the host CPU when 
any data are available cr when the received data reaches some level (/.e. 16 
bytes). When notified, the CPU reads all the data in the input FIFO, and 
,5 stores the data temporarily in a buffer m system memo,, (not shown). The 

■ bottom protocol, PPP (see Fig. D can start to process the data, but it cannot 
pass up the data to the next layer until the entire packet Is rece.ved. 

once the whole packet is received, the PPP portion of the software network 
30 stack passes the data up to the second protocol (,P). The IP software , en 
processes the ,P header and, after verifying the header checksum, passes the 

■ packet to the TCP handler. The TCP handler then checks its checksum, and 
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passes the data.on to the appropriate application, as specified by the PORT 
number in the TCP header. 

Because most modems in computers today are used to connect to the 
5 intemet. it makes it economically feasible and practical to optimize a modem 
for this environment. What this entails is embedding in the modem system, 
the ability to handle the necessa^ network protocols and use the knowledge 
of the protocols to tune the transmission characteristics of the modem, This is 
the same rationale behind the popularity of Window's accelerator graphics 
0 cards. Because graphic chip manufacturers know that a vast majority of PC's 
today run the Microsoft Windows ® operating system, they fine-tune their 
architectures to enhance the performance in this environment. This would not 
be practical if there were a number of operating systems with different graphic 
APIs, each with a significant portion of the market place. However, with the 
5 one over-riding standard, most graphic card manufactures have chosen to 
^ optimize their hardware for the Windows environment, even though today's 
Pentium class processors are very capable of handling the graphic chores 
without external support. This is because the function is required in most 
circumstances, and it is advantageous to offload the host processor so that .t 
20 has that much more MIPs to run standard applications. 

A similar situation now exists in the modem card market. It would therefore 
be advantageous to embed the Intemet network protocol stack, along with 
soecial looic, thereby enabling the modem device to become Intemet-ready, 
such that the modem system offloads much of the network protocol 
processing from the main CPU, while improving the overall performance of 
the communication system. 

NUMMARY OF TUP INVENTION 

The invention embeds the Intemet network protocol stack, along with special 
logic, thereby enabling the modem device to become internet-ready. As- a 
result the modem system offloads much of the network protocol process.ng 
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from the main. CPU and improves the overall performance of the 
communication system. The invention provides an Internet-aware modem 
which combines any number of point-to-point devices with the network 
protocols necessary to communicate on the Internet, where these devices 
5 include various speed traditional modems from 2400 kbps to 56 kbps, ISDN 
modems, newer xDSL modems, and digital cellular modems. 



.c^ftndina Data 



10 in a system equipped with an Intemet-ready modem, the Internet application 
first sets UD the socket parameters. These include the destination port 
number, the type of connection (TCP/UDP), the TOS (Type-Of-Service) 
requirements, and the destination IP address. When the network stack on an 
Internet-ready modem card gets this information, it attempts to start a 

1 5 connection by sending out a SYN packet. This packet is passed to the IP 
■ engine, which attaches the IP header and calculates the IP header checksum. 
The packet is then passed to the PPP handler which attaches the PPP 
header, escapes the data, and appends the PPP checksum. After PPP 
encapsulation, the resulting network packet is sent through the output FIFO to 

9 0 the modem core. For this. packet, the TCP engine indicates to the packet 
analyzer block that it is a SYN packet. The packet analyzer then indicates to 
the modem that this is a stand alone packet and that it can be sent 
■ immediately. Upon receiving this information, the modem sends the network 
packet out without first waiting the normal 50- ms to see if additional 

25 information is forthcoming. 

After the destination socket sends a return SYN-ACK packet, an ACK packet 
is sent from the modem card. This packet follows the same steps as those for 
the SYN packet. At this point, the socket connection is up, and the application 
3 0 software (such as a Web browser) is notified. The application can now send 
Ks data directly to the modem in a data packet format, in this example, where 
the^ application is a Web browser, the application can send an HTTP request 
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directly to the modem system via a packet interface as opposed to the serial 
port 1/0 interface in a regular modem system. DMA style data transports can 
be used for this purpose. In this method, a data byte count is programmed 
into the packet interface. Data can then be automatically transferred from 
. memory into a modem card without further intervention from the host CPU. 
After all the data have been transferred, an interrupt from the modem card 
can be sent to the host CPU indicating that the data transfer is complete. 

AS the data arrive at the modem card, they are sent (in this example) to a 
0 TCP data output buffer.' After all the data are received or when the maximum 
data size per packet has been received, the TCP block begins calculating the 
checksum. The packet is encapsulated in the same way as the SYN packet, 
in parallel to this, the TCP engine indicates to the packet analyzer block that 
,he destination port for the packet is 80, which is the well-known HTTP port. 
5 The packet analyzer then knows that there are no more data and, aga,n, the 
■modem should send the current packet immediately. 

■ Rppfiivina Data 

.0 When receiving network packets, the data are sent from the modem core 
through the input FIFO to the PPP engine: which parses the PPP header, 
unescapes the data, and starts a running check on the packet for checksum 
calculations. If the engine determines that the encapsulated data ,s an 1, 
packet, it enables the" IP engine, and all data past the PPP header ,s 

. 5 forwarded to the IP engine. The ,P engine parses the IP header, checks the 
Checksum, and if it detem^ines that the encapsulated protocol is TCP, then ,t 
sends all data past the IP header to the TCP engine. The TCP engine then 

■ ■ parses the TCP header andsends the data portion to the security layer, if the 
data is HTML data, it can be passed through a ratings check that parses out 

30 ■ rating tags of pages. If the page has a rating below or egual ,c the modem 
cards setting, then the data are allowed to pass. If the rating exc eds th 
setting on the card, a message indicating so is passed on instead. I. the page 
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contains no ratings, a bit can be set to either pass or block the page. All non- 
HTML data are passed directly to the TCP data buffer. 

As the data are being written into the buffer, a running count is kept to see 
5 how much data have been received. At the end of the network packet, if the 

PPP checksum indicates that the entire packet was received without errors, 
. then an interrupt can be generated to the host CPU. The application can then 

read the received data count, and program a DMA transfer to transfer data 

from the TCP buffer into main memory. 
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RRIFF HESCRIPTION H P THE DRAWINGS 

Fig. 1 is a block diagram showing connection protocols used by the Intemet 
and their hierarchical relationship; 

Fig. 2 is a block diagram showing a typical modem subsystem; 

Fig. 3 is a block schematic diagram showing an Internet-ready modem 
system according to the invention; 

Fig. 4 is a block schematic diagram showing a modem having a full network 
stack according to t he invention; 



Fig. 5 is a block schematic showing a PPP function according to the 
25 invention; 

Fig. 6a is a block schematic diagram showing a prior art modem and network 
card; 

30 Fig. 6b is a block schematic diagram showing a modem according to the 

- • - ■ invention and an enhanced- Ethernet network card; 

- Fig. 7 is a schematic diagram showing fields used in a PPP protocol packet to 
determine latency according to the invention; , 
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Fig. 8 is a block schematic diagram showing optimization based on TOS 
according to the invention; 

Fig. 9 is block schematic diagram showing an optimization based on 
5 destination port according to the invention; 

' Fig. 10 is a block schematic diagram showing an optimization based on 
packet state according to the invention; 

0 Fig. 11 is a block schematic diagram showing combined latency tables 
according to the invention; 

Fig. 12 is a block schematic diagram showing an enhanced modem system 
according to the invention; 



Fig. 13 is a block schematic diagram showing received -packet data flow 
through an HTML sniffer according to the invention; and 

•Fig. 14 is a block schematic diagram showing an HTML sniffer according to 
0 the invention. 

ncTAii FH nFRCRIPTlON HFTHF, INVENTION 

The invention provides an .Internet-aware modem which combines any 
,5 number of point-to-point devices with the network protocols necessary to 
communicate on the Internet, where these devices include various speed 
traditional modems from 2400 kbps to 56 kbps, ISDN modems, newer xDSL 
modems, and digital cellular modems. The invention embeds the Internet 
network protocol stack, along with special logic, thereby enabling the modem 
10 device to become Intemet-ready. As a result, the modem system offloads 
much of the network protocol processing from the main CPU and improves 
the overall performance of the communication subsystem. 

The invention provides several technologies that enhance modem 
3 5 performance and efficiency when used with Internet protocols. These 

technoloaies include: 
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• Block Based Communication, 

• Latency Optimization, 

5 

• Reduced Processing Power, 

• Reduced Energy Requirements, and 
10 • Security Eniiancements. 

n^ta Transfer Overhe ad Reduction 

Modems today all communicate via serial ports. This serial communication 
1 5 .has several performance disadvantages over other communications devices, 
such as Ethernet adapters, which communicate to the host CPU by sending 
and receiving blocks of data via DMA (Direct Memo.7 Access). 

.qprial Co nnmiinications 

.0 Serial communication using older serial hardware (e.g. UARTs) require an 
interrupt for eveo< character sent or received. This causes so much overhead 
that it is not possible to communicate at speeds over 19200bps without 
dropping data on most computer systems. Second generation senal 
hardware (e.g. the 1 6550 UART and its derivatives) are able to buffer up to 1 6 

7 5 bytes on send and receive and can delay interrupts until a buffer reaches a 
. certain level. This reducesite .number of intern^pts required to transfer data to 
and from the modem. This allows modem modems to achieve senal data 
rates of 56000bps to 230400bps without losing data on most CPU's. 

30 Although high speed serial communication using second generation serial 
hardware is now possible, a. these higher data rates serial communlcat,ons 
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can cause a noticeable degradation in system performance, especially when 
the computer system is running Internet enabled action games or multi-media 
communication programs. Thousands of interrupts each second are required 
at the higher data rates (see Table 1 below.) 

Table 1. Serial Interrupt Requirement Example 



Given a 16550 UART with inierrupis set at: 

16 bytes transmit trigger 
14 bytes receive trigger 

Receive interrupts: 

23p400bps/9bits per byte=25600Bps/14 bytes per interrupt = 1828 interrupts per second. 
Transmit Interrupts: 

230400bps/9bits per byte = 25600Bps/16 bytes per interrupt = 1600 interrupts per second. 



Each interrupt requires an interrupt service routine to read and write data 
10 to/from the serial hardware and to/from the Computers Operating System. 
These interrupt routines read and write to 1/0 ports that are not efficient use of 
system resources. 
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Ootimizinn Using RInrk Transfers 

There has been talk about a next generation UART that would have either 32 
or 64 byte buffers to reduce. the number of interrupts and load on a system. 
While this may be helpful, the inventor's have recognized that the correct 
solution is to optimize the modem for Internet protocols and transfer data as 
bloci<s of data packets. 
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Block based Communication to/from modems has not been previously 
considered because the Internet protocols designed to interface a 
modem/serial device are serial based (SLIP/PPP) and are traditionally 
implemented in the computer system's operating system. Using the herein 
5 described invention, it is advantageous to move the network stack protocols 
from the computer operating system into the modem. The layers of the 
network protocol that can be implemented in a hardware device in accordance 
with the invention can range from just the PPP layer all the way to the IP, 
TCP, and UDP layers. 
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Example: Block Based Interrupt Requirement 

Assuming an average 100-byte IP packet: 
25600 Bps / 100 = 255 Interrupts per second. 



• AS is shown in the above example, transferring blocks instead of chunks of 
characters, as in the serial solution, reduces the number of interrupts 
required. An added benefit is that the transfer routine can use direct memo^ 
access (DMA) to pass data instead of slower 1/0 port pumping. Currently 
2 0 serial port hardware and software do not support DMA. 

This enables the development of software that can produce faster, more 
efficient data handling routines because the host CPU is relieved of handling 
transferring of individual bytes of data. 

25 Rptiuced Latency 

. once the modem knows that it is dealing with IP packets, it has knowledge of 
where data units start and stop. Modem protocols, such as V.42 and V.42b,s, 
can be optimized to take advantage of this knowledge. 

V 42 has an outdated view of what kind of data are being carried over, a 
modem, but if the network stack is embedded alongside a modem core, ,t can 
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indicate to the modem core the end of data units. The modem core can then 
segment its V.42 packets accordingly. This reduces latency on 
retransmission because retransmission would have a higher probability of 
affecting only one IP packet. Knowledge of the end of a packet can also be 
5 used to reduce the waiting for more data timeout that the V.42 protocol 
introduces. If it is known that the last byte received is an end of a physical 
block of data, the modem need not wait around, or can reduce the time it 
waits, for more data to be sent to it before it sends that data it has ready to 
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send. 



This aspect of the invention can be extended to perform IP and TCP packet 
snooping to optimize further what gets sent when and how long the V.42 
protocol waits before compressing and sending the current block. For 
example, the TOS field in the IP header can be used to determine the amount 
1 5 of latency used in the transmission of the packet. If the packet is a high 
■priority packet the system may decide to send the packet immediately, not 
checking to determine if there are more packets ready to send. The system 
can wait varying lengths of time for more data based on this TOS information. 

. 0 Additional latency optimization can be achieved by checking the TCP header. 
If the SYN flag is set in the TCP header, then the data should also be sent 
immediately because nothing more can happen until the SYN-ACK is returned 
from the other side of the connection. 

■, 5 Also unlike previous advances to modem technology that required that the 
same technical advances be on both the receiving and sending ends of the 
communications link, the herein disclosed modem can operate and ,s 
compatible with all existing modems today. Therefore, it Is possible to gam 
performance Increases by updating only one end of the connection. In this 

30 way, adoption of the technology is not dependent on changes m ISP 
infrastructure. 
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p^^nroH Prorflssina P ^wpr Reouirpri from Host CPU. 

By embedding the network stack along with the modem core, a marked 
reduction in processing power that is required to connect and communicate 
5 on the internet is possible. This allows small, low power, low cost devices to 
communicate via the Internet using modems. Examples of these types of 
devices include game consoles, PDAs. toys, and other consumer electronic 
and mobile electronic appliances. 



10 Prnnfissor Power Rp n'nrtinn of PPP 

The PPP protocol, requires that packets include a CRC appended at the end 
of each packet. This calculation requires what could be a significant amount 
" of processing power on low-end processors. Other aspects of the protocol, 
15. such as escaping data and parameter negotiations, require memory accesses 
for each byte when implemented as a software solution. By implementing 
PPP in the modem, all negotiations can be kept local to the modem 
subsystem, thereby relieving system bus traffic and processing overhead. 

20 Prnrpssor Pow^r Reduction of Fm heddina IP 

Embedding IP offloads the header checksum calculations from the host 
processor. It also keeps ICMP echo packet processing local to the modem 
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card. This protocol is used for PING applications. 

Prnrpssor Po '^/ar Rpriuction nf Fmhpridino UDP . 

Though it is possible to use. UDP as an encapsulation device requiring little 
processing power, when used with checksums, UDP can require sorne 
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processor resources. 1. should be'noted here that most .hin Interne, clients 
are based on IP/UDP to transmit their data. 

D,^..,.,nr Pnw "' P°H„Minn of Fmhortdinq TCP 

TCP is a much more complicated protocol than UDP and, thus, requires much 
more processing power. The TCP has many states and requires checksums 
,0 be preformed on packets. For embedded products that require TCP 
■ support the invention described herein provides a way to offload all the 
0 complexity and processor requirements onto a dedicated hardware circuit. 

Pnrtahilitv nf f^olution 

By embedding the network stack inside of the modem subsystem, the same 
modem system can now be used across multiple computing and system 
platforms. Because no porting of any network stack software is requ.red, 
moving the modem into different systems becomes very easy. Th,s ,s 
especially important in the embedded systems market that does not have one 
or two main OS's but instead is made up of a number of different OSs, 
RTOS's and in some cases, no OS. The embedded systems market .s also 
Characterized by being made up of a number of inccmpatible processors^ 
This lack of an overriding standard also favors a highly portable network 
solution. 
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RpHiiced ^r^^rnM Requirements. 
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The herein described invention is also very efficient in terms of energy 
rements, A highly optimized state machine reduces by two orders of 
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magnitude the clock rate required to perfomn the functionality of the internet 
suite of protocols. This translates into extended battery life and less heat 
generated by products designed with the herein described invention. 

5 .g^pnuritv E nhancements 

By implementing the network stack in hardware along with the modem, the 
invention provides a ve^ secure, unhackabie network stack. This is due to 
the hardware architecture Implementation that disregards any packet received 
unless there is already a socket connection set up for it. Furthermore, the 
packets do not get past the modem card, therefore making any interact.on 
between unrequested packets and software Impossible., 

In addition, by including an HTML packet sniffer, it is possible to decode 
5 HTML rating taas. The packet sniffer Interprets bytes In the packet buffer, and 

can be set up to pass only those pages that are within its preset rating level. 

For pages that exceed the programmed rating level, the HTML sniffer passes 
- up a failed retrieval message, and does not allow the HTML content past the 

modem subsystem. This turns the modem Into a content driven minM.rewall. 

For those pages that do not include a rating tag, the sniffer can be configured 
either not to pass these pages at all, orto aliowthe pages to be passed. The 
rating level can be programmed only via board settings, i.e. hard w.red. The 
advantage of implementing this solution In hardware is that for parents or 
anyone who wishes to filter out certain Web sites, it is impossible to get 
around this system without taking the modem card out of the system. With 
any software solution, "the aser couid simply load a non-filterlng browser or 
disable a certain plug-in, and the filter would be bypassed. By providing the 
■ filter in hardware on the modem card, there is no way to bypass the function. 
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Fig. 3 is a block schematic diagram of an Internet-ready modem system. 



5 Sending Data 

In a system equipped with an Internet-ready modem 31, the internet 
application first sets up the socket parameters. These include the destination 
port number, the type of connection (TCP/UDP), the TOS (Type-Of-Service) 

0 requirements, and the destination IP address. When the network stack 30 on 
the Internet-ready modem 31 gets this information, it attempts to start a 
connection by sending out a SYN packet. This packet is passed to the IP 
engine within the network stack, which attaches the IPiieader and calculates 
the IP header checksum. The packet is then passed to' the PPP handler 

5 within the network stack which attaches the PPP header, escapes the data, 
•and appends the PPP checksum. After PPP encapsulation, the resulting 
network packet is sent through the output FIFO 32 to the modem core 33. For 
this packet, the TCP engine indicates to the packet analyzer block 34 that it is 
a SYN packet. The packet analyzer 34 then indicates to the modem that this 

0 is a stand alone packet and that it can be sent immediately. The modem 
upon receiving this information sends the network packet out without waiting 
the normal 50 ms to see if additional information is forthcoming. 

After the destination socket sends a retum SYN-ACK packet, an ACK packet 
5 Is sent from the modem card. This packet follows the same steps as those for 
the SYN packet. At this point, the socket connection is up, and the application 
software (such as a Web browser 21) is notified. The application can now 
send its data directly to the modem in a data packet format. 

0 In the example shown in Fig. 3, where the application is a Web browser, the 
application can send an HTTP request directly to the modem system via a 
packet interface 38 as opposed to the serial port I/O interface in a regular 
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modem system .(see Fig. 2). DMA style data transports can be used for this 
purpose, m this method, a data byte count is programmed into the packet 
interface. Data can then be automatically transferred from memory into a 
modem card without further intervention from the host CPU. After all the data 
5 have been transferred, an interrupt from the modem card can be sent to the 
host CPU 23 indicating that the data transfer is complete. 

As the data arrive at the modem card, they are sent (in this example) to a 
TCP data output buffer. After all the data are received or when the maximum 

1 0 data size per packet has been received, the TCP block begins calculating the 
checksum. The packet is encapsulated in the same way as the SYN packet, 
in parallel to this, the TCP engine in the network stack indicates to the packet 
' analyzer block that the destination port for the packet is 80, which is the well- 
known HTTP port. The packet analyzer then knows that there are no more 

1 5 data and, again, the modem should send the current packet immediately. 

RprRivino Data 

When receiving network packets, the data are sent from the modem core 33 
00 throuah the input FIFO 35 to the PPP engine in the network stack, which 
parses the PPP header, unescapes the data, and starts a running check on 
' the packet for checksum calculations. If the engine determines that the 
encapsulated data is an IP packet, it enables the IP engine in the network 
stack, and all data past the PPP header is fon/varded to the IP engine. The IP 
engine parses the IP header, checks the checksum, and if it determines that 
the encapsulated protocol is TCP, then it sends all data past the IP header to 
the TCP engine in the network stack. The TCP engine then parses the TCP 
header and sends the data portion to the security layer 36. If the data .s 
HTML data, it can be passed through a ratings check that parses out rating 
tags of pages. If the page has a rating below or equal to the modem cards 
settina. then the data are allowed to pass. If the rating exceeds the sett.ng on 
the card, a message indicating so is passed on instead. If the page contains 
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no ratings, a bit oan be set to either'pass or biooi< the page. Ail non-HTML 
data are passed directly to the TCP data buffer 37. 

AS the data are being written into the buffer, a running count is kept to see 
3 how n^uch data have been received. At the end of the network packet, ,f the 
PPP checksum indicates that the entire packet was received without errors, 
then an interrupt can be generated to the host CPU 23. The appiicaticn can 
.nen read the received data count, and program a DMA transfer to transrer 
data from the TCP buffer into main memory. 

10 ' 

Pp^|ii,^^ nftlic Inveniion 

The following discussion describes various features of the invention: 
15 1. Modem as a Block Device. 

2. Latency Optimization based on packet parameters: 

a) Basic End of Packet Optimization, 

b) Optimization based on IP TOS flag, 

c) Optimization based on UDP/TCP port numbers, 

25 d) Optimization based on TCP State, and 



20 



e) Latency Table. 
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3. Modem as a complete Internet Access Device: 
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a) Partial Stack, solutions: 

i) PPP/IP, 

ii) PPP/IP/iCMP, and 

iii) PPP/IP/ICMP/UDP; and 

b) Complete Stack Solutions (PPP/IP/ICMP/UDP/TCP). . 

4. Enhanced Security and HTML filtering in an Internet enabled Modem. 

1 5 The following discussion describes the above features in more detail. 
Modem as a Block Device 

Depending on the network layers included with the modem hardware, different 
data formats are sent to the modem subsystem. In any of the 
20 implementations, however, DMA transfers can be used to optimize CPU 
overhead required for the transfers. 

Refer to Fig. 4 for the following discussion. In the implementation where the 
entire network stack 40 is included with the modem card 41 , only the 
25 application 42 data need be transferred. Software applications 44 
communicate with the modem card via a socket API 43. 

At a minimum, just PPP can be added to the modem. The function of PPP is 
to transform IP packets (blocks of data) into a serial stream so that it can be 
30 transported over a serial device (see Fig. 5). The PPP protocol is also 
responsible for negotiating the parameters that are used to transmit data oyer 
the serial link (e.g. compression schemes and escaped bytes). With the PPP 



wo 99/65219 PCT/US99/13184 



19 



function 50 performed inside the modem, the communication between the 
modem and the IP protocol stack software operates in a manner that is similar 
to that in which an IP stack communicates with an Ethernet card. 

5 As with an Ethernet card, packets are shipped from the IP protocol stack to 
the device driver, in the modem's case, the device driver is a simple 
interfacing software program that transfers blocks of data to and from the 
modem and the host computer. Compare the architecture of the prior art 
modem of Fig. 6a with that of a modem according to the invention, as shown 
10 in Fig. 6b. 

This embodiment of the invention enables all of the efficiency benefits 
described above, and is an attractive solution because-it can be implemented 
by adding only a minimum amount of extra logic to existing modem chip sets, 
15 and because it requires as little as 512 bytes of memoi7 for support. This 
■ makes it very cost affordable to add to any existing modem. 

Latency Optimization 

Traditional modems have no knowledge of the type of data they carry and 
20 their protocols are optimized for interactive character based interfaces. The 
traditional modem protocols have a built in 50ms delay before sending 
information. This delay is present because the modem has no idea of where 
the data stops and starts, so it waits until it knows no more data are going to 
be sent. 

25 

With the popularity of the intemet. almost all modems today are used to 
-- - connect to the Intemet. Using this knowledge and the information on when 
the packets begin and end can help optimize modem transmissions. This 
optimization can reduce the amount of time it takes to move an Intemet 
■ 30 protocol packet from one modem to another by reducing or eliminating the 
50ms delay built into the modem protocols. This feature of the invention can 
be extended using different parts of the network packet to make decisions 
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whether there should be ahy delay or how iohg it should be before the modem 
processes a paoket. The hardware module that hahdies this optimization ,s 
the packet analyzer block 34 (see Fig. 3). 
p ^ =ir Fnd o f Parkst Octimization 

At the most basic level, one could use the knowledge of the end of the PPP 
packet ,0 tell the modem protocols to wait a small amount of time before 
sending the packet (see Fig. 7). In the traditional modem model, if there were 
not enough bytes to make a modem protocol frame (such as V42) the modem 
would wait for more data, up to 50ms, before timing ou, and sending the. 
packet. With knowledge of the end of the PPP packet and the encapsulated 
protocol, the modem could expedite the sending of the packet knowing that ,t 
has a complete packet. 

This algorithm is useful for PPP sub-protocols, such as LCP (Link Control 
protocol), PAP (password Authentication Protocol), CHAP (Challenge 
Handshake Authentication Protocol), and NCP (Network Control Protoco . 
With these and similar PPP sub-protocols, packets transmitted are stand- 
alone in that ail infomiation is contained within a single packet. Also, ,n most 

waiting for a response from the other device. Therefore, if the packet 
analyzer detects that a PPP packet contains a PPP sub-pro.ocol. when „ 
detects the PPP FCS field it can instruct the modem to wait only 2 ms before 
sending the data, instead of the norma, 50 ms. The reason to wait a minimum 
Of at least 2 ms is that in the transition between the LCP, Au,hentlcat,on, an 
NCP phases of the PPP negotiations, back to back packets can be sent out. 
However, there would never be mdre than two back to back packets and the 
second packet always follows Immediately within 2 ms of the first packet. 
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Further optimization can occur by looking at tine command code of the PPP 
sub-protocol packet. An example matrix of command types and the 
corresponding latency setting are shown in the Table 1 below. 

Table 2. Matrix of Command Types and Corresponding 

Latency Setting 



Prntncnl 




Command Code 


i Latency Setting 


LCP 


UA\J I 


Confiquration Request 


0 ms 


OyOP 


■ Confiauration Ack 


; 2 ms 




\JA\J\J 


Confiquration Nak. 


i 0 ms 




UaU^ 


Confiauration Reject 


i 0 ms 


1 


UAUO 


Termination Reouest 


1 0 ms 




0x06 


Termination Acl 


' 0 ms 




0x07 


Code Reject 


i 2 ms 




0x08 


Protocol Reject 


r2 ms 




0x09 


Echo-Request 


1 2 nis 




OxOA 


Echo-Reolv 


i 2 ms 




OxOB 


Discard-Reuuest 


i 2 m.s 


PAP 


0x01 


Authentication-Request 


1 0 ms 


CHAP 


0x02 


Challenae Response 


1 2 ms 


NCP 


0x01 


Confiauration Request 


i 0 ms 


0x02 


Confiquration Ack 


i 2 ms 




0x03 


Confiauration Nak 


1 0 ms 




0x04 


Confiquration Reject 


1 0 ms 




0x05 


Termination Request 


1 0 ms 




0x06 


Termination Acl 


' 0 ms 



n ptlmizino Based On IP H aader Fields 

10 , Qptimizinn Based o n tha TP'S Field 

FOR IP, TCP, and UDP packets, a more intelligent decision on how long to 
wait or when to send packets can be determined by examining the type of 
service (TOS) field in the IP header. The TOS field describes the priority and 
1 5 reliability requested for the packet. The properties that are settable for the 
TOS field are Minimize Delay, Maximize Throughput, Maximize Reliability, 
and Minimize Cost. More than one of the TOS flag properties can be set at 
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one time. This information can be used to set variable waiting time delays or 
to send what is in the modem buffer immediately. 

Fig. 8 shows how it is possible to look inside the TOS flag 80 for a minimize 
) delay property and use that information and the information on when the IP 
packet ends to tell the modem protocols to send the packet immediately. 



OotimizinQ Based on the Fncapsuia tsd Protocol 

1 0 Another optimization that can be performed based on IP header fields is to 
base the latency setting on the protocol field. " Most ICMP and IGMP packets 
are self contained therefore minimum wait times are needed after they are 
sent. After the packet analyzer determines that the IP packet contains either 
an IGMP or ICMP packet, it signals to the modem core to send the packet 

1 5 .immediately. 

Optimization Based on Packet Ports 

Certain kinds of Internet services have information distributions that require 
.20 just one packet of data to be sent and received. With these types of services 

it is optimal always to send a packet immediately without waiting for more 

data. Other Internet services have yet other packet distribution patterns that 
• could be optimized for UDP and TCP, the major protocols that are used on 

top of IP. Both use ports to describe services. Fig. 9 provides an example of 
25 how the port information carried in both UDP and TCP is used to optimize 

modem latency. 

The latency table 90 contains a table of ports and the amount of time to wait 
after the end of the packet for more data. An example of optimizing using this 
30 method is the DNS application. In this application, the entire data portion of 
the message can easily fit in one Internet packet. Therefore, if after 
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examining the destination port in the UDP header it is determined that .t .s a 
DNS packet, the packet can be sent immediately because there are not any 
further packets coming. Table 3 below provides an example protocol-port 
latency table. 

Table 3. Latency Table - Example I 



Protocol 


! Port 


i Application | 


Wait Time 


TCP 


I 0x07 

i 


: Echo 


0 ms 




1 0x17 


Telnet j 


50 ms 




■; 0x19 


SMTP ~ 1 


10 ms 




: 0x50 


HTTP 


0 ms 




; 0x6E 


i P0P3 


0 ms 

* 


UDP 


i 0x07 

1 


; Echo 


0 ms 




i 0x53 


i DNS 

i 


0 ms 



10 



15 



20 



Latency 



OatimiTatinp nn Panket Slate 



TCP is a state-based protocol and certain states have well known properties 
that can be used for latency optimizalion. An example is the three-way 
handshake with which all TCP connections start. The first few packets of this 
transaction are small packets that must be sent before any further 
communications can take place. The invention can noticeably improve the 
■time this connection process takes. This can be a very noticeable 
improvement, especially when operating software that connects many TCP 
connections at one time during one transaction, as with a Web browser. 

,n Fig 10, infomnation from the IP header (TCP protocol type) 100 and the 
TCP state 101 are used to look up a latency value to pass through to the 
modem protocol at the end of the packet. Table 4 below provides an example 
■ latency table using this information. 
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Table 4. Latency Table - Example II 



TCP Flags 




Wait i ime 


URG 


AC 1 PSH 
^ \ 


RST 


SYN 


FIN 


X 


1 0 


0 


X 


0 


2 ms 


X 


X i X 

1 


X 


1 


X 


2 ms 


X 


X i X 


X 


X 


X 


2 ms 


X 


X 1 1 


X |x 


X 


50 ms 



X = Don't Care 

Thft Lstep r-v Table 

Latency tables are state machines that have a number of inputs that are 

■ triggered by a packet's oharacterislics. From these inputs the latency table 
produces an optimized latency value for the modem protocol, effectively 
optimizing each packet as it passes through the system. A block schematic 

1 0 diagram of the latency tables is shown in the Fig. 1 1 , in which the informatton 
discussed above is combined. 

The IP latency rssolver 1 10 takes the inputs from the IP sub-protocol latency 
table 1 11 and the IP TOS field latency table 112 and selects the lower of the 

1 5 two values. The TCP latency resolver 1 1 3 performs a similar function for the 
destination port latency table 114 and the TCP state latency table 115. The 
IP latency resolver and TCP latency resolver outputs are muxed 117 to 
produce a combined latency value therefor. (The mux selection is determined 
by the protocol field in the IP header as parsed by the IP Sub-Protocol 

20 Latencv Table 111.) A value is also provided by the PPP latency table 116. 
This value is muxed with the muxed 117 value of the IP latency resolver and 
TCP latency resolver. The mux selection for mux 118 is determined by the 

■ protocol field in the PPP header as parsed by the PPP latency table 1 1 6. Tne 
final latency value is then sent to the modem subsystem. 
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MndPm as a nnmnlste Intprppt Acc ess Device 

The extended Internet modem mode! is a stand alone, embeddable. highly 
integrated communications product that can Internet enable almost any 
electronic device (see Fig. 12), This solution has a number of advantages 
over the processor based solutions discussed above. More specifically, this 
architecture allows the addition of Internet support to non-computer 
applications, such' as game consoles and VCR's. It is also ver^ useful for 
those devices that have limited memory footprints and do not need network 
support all the time. An example of this is Palm Pilot type devices, where the 
only time the added network support is needed is when the modem is used. 
An advantage of the invention is that it is not necessary -to waste memory 
resources on features that are not used all the time. 



Fnhanced .qpcuritv Benefits 



As stated above, one security benefit of having a hardware based network 
stack is that only those packets received that are destined for a preconfigured 
20 socket connection a.^e allowed past the modem subsystem. All other packets 
are filtered out at the hardware level, making any interaction between these 
packets and software impossible. Also, with the addition of the HTML sniffer, 
V-Chip like filtering can be provided that cannot be easily circumvented. 
Block diagrams of the HTML sniffer are shown in Figs. 13 and 14. 

.- ln-Fig.-1.3, a-packet 138 .is received at the TCP engine 139. The packet is 
. destined for a specific socket. The HTML packet sniffer' 144 has a preset 

rating 146 that is applied to the packet to determine if the packet ,s to be 

placed in the received packet buffer 145. 



PCT/US99/13184 

WO 99/65219 

26 

AS shown in Fig. 14, within the HTML packet sniffer, the KHP response 
parser 140 takes received packets from the socket 141, and interprets the 
HTTP header to determine d the data content contains valid HTML data. i. 
so it enabies the HTML rating decoder 1 42, which begins tc parse the HTML 

5 data for rating tags. The HTML decoder writes all received data to the 
received packet buffer 1 45 (including the HTTP header), and at the same t,me 
parses tags, if it detects a rating tag, it compares the page's rating tc the 
card's preset rating level, if it passes, then the page continues to be stored ,n 
,he receive buffer, if the page fails, then ail further .data are suppressed, the 

,0 memory buffer is reset to the point prior to receiving the current packet, and a 
reject message is stored in memo^. if the page contains no ratings at the 
head of the page, the card can either be configured to pass the page or reject 
the page. 

Althouoh the invention is described herein with reference ^^^^f '''' 
.embodiment, one skilled in the art will readily appreca e ha. or er 
applications may be substituted for those set forth herein wrthout depart ng 
ZTZ spirit and scope of the present invention. Accordingly, the ,nven.,on 
should only be limited by the Claims included below. 
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1 . A modem, comprising: 
a modem core; and 

5 a network stack embedded in liardware which executes network 

protocols to allow said modem to communicate on an electronic network. 

2. The modem of Claim 1 , wherein said network stack comprises: 
an Internet network protocol stack. 

10 

3. The modem of Claim 1 , wherein said network stack sends and receives 
blocks of data. 

4. The modem of Claim 1, wherein network -protocols that are 
1 5 implemented in said network stack include any of the protocols required by 

ppp_ ip^ 7cp_ and UDP communications layers. 

5. The modem of Claim 1, wherein said network stack supports direct 
memory access (DMA) operations to optimize CPU overhead required for 

20 data transfers. 

6. The modem of Claim 1 , wherein said network stack performs IP and 
, TCP packet snooping. 



25 



7. The modem of Claim 1 , wherein the TOS field in an IP header is used 
by said network stack to determine the amount of latency used in the 
transmission of a packet. 



8. The modem of Claim 1 , wherein said network stack performs latency 
3 0 optimization by checking a TCP header. 

9. The modem of claim 1 . wherein all protocol negotiations are kept local 
to said modem by said network stack. 
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,0 The modem of Claim 1, wherein said network stack 
disregards any packet received unless there is already a socket conneofon 
set up for it. 

1 1 The modem of Claim 1 , furtiier comprising: 

a packet sniffer for decoding HTML rating tags, wherein said packet 
sniffer only passes those pages that are within a preset rating level. 



10 12. ■ The modem of Claim 1,1, wherein said packet sniffer is configured 
either not t 

allow said unrated pages to be passed. 



25 



either not to pass unrated pages that do not include a rating tag at all, or to 



13. The modem of Claim 1 1 , wherein a rating level can be programmed 
1 5 only via hard wired settings. 

14. The modem of Claim 1 , wherein software applications communicate 
with said modem via a socket API. 

20 15. A modem, comprising: 
a modem core; and 

a network stack embedded in hardware which executes network 
protocols to allow said modem communicate on an electronic network, 
wherein said network stack comprises an Internet network protocol stack. 



16 The modem of Claim 15, wherein said network stack further comprises: 
a PPP stack for transforming IP packets into a serial stream for 
transport over a seriai link^ and for negotiating parameters that are used to 
transmit data over said serial link 
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17 The modem of Claim 15, further comprising: 

a packet analyzer module for using different pans of a network packet 
to make decisions whether there should be a delay and. if so. how long .t 
should be before said modem processes a packet. 

18. The modem of Claim 1 5, further corrlprising: 

a packet analyzer module for using knowledge of the end of a PPP 
packet to tell said modem to wait a minimum amount of time before sending a 
packet. 

1 9 The modem of Claim 1 8, wherein said paoket analyzer module detects 
PPP sub-protocols, including any of LCP (Link Control Protocol), PAP 
(password Authentication Protocol), CHAP (Challenge Handshake 
Authentication Protocol), and NOP (Net^vork Control Protocol), and uses this 
information to determine the amount of latency used in the transmission of a 

' packet. 

20 The modem of Claim 1 9. wherein said packet analyzer module 
examines a command code of a PPP sub-protocol packet, and uses this 
information to determine the amount of latency used in the transmission of a 
packet. 

21 The modem of Claim 18, wherein said packet analyzer module 
examines a type of semce (TOS) field in an IP header to determine the 

2 5 amount of latency used in the transmission of packets. 

22. The modem of Claim 21 , wherein said TOS field describes priority and 
reliability requested for a packet. 
30 23 The modem of Claim 21, wherein properties that are settable for said 
TOS field include any of Minimize Delay, Maximize Throughput, Maximize 

Reliability, and Minimize Cost. 
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24. The modem of Claim 23, wherein more than one of said TOS flag 
properties can be set at one time. 

5 25. The modem of Claim 18, wherein said packet analyzer module 
examines a TOS flag for a minimize delay property, and wherein said network 
stack uses said minimize delay property and information on when an IP 
packet ends to instruct said modem to send a packet immediately. 

1 0 26. The modem of Claim 1 8, wherein an optimization is perfomned based 
on IP header fields. 

27. The modem of Claim 26, wherein a latency setting is based on a 
protocol field. 

15 

• 28. The modem of Claim 26, wherein port information carried in both UDP 
and TCP is used to optimize modem latency. 

29. The modem of Claim 15, further comprising: 
20 a latency table. 

30. The modem of Claim 29, wherein said latency table comprises: 

a table of protocols; 
a table of ports; and 

25 a table of amount of time to wait after the end of a packet for more 

data. 



■ 31 . The modem of Claim 29; wherein information from any -of an IP header 
and a TCP state is used to look up a latency value to pass through to said 
3 0 modem protocol at the end of said packet. 
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32. The-modem of Claim 29, wherein said latency table is a state macliine 
that has a plurality of inputs that are triggered by a packet's characteristics, 
wherein said latency table produces an optimized latency value for a modem 
protocol from said inputs, and wherein each packet is optimized as it passes 

5 through said modem. 

33. The modem of Claim 29, further comprising: 

an IP latency resolver that takes input values from an IP sub-protocol 
latency table and an IP TOS field latency table, and that selects a lower of 
1 0 said two values. 

34. The modem of claim 29, further comprising: 

a TCP latency resolver that takes input values fFom a destination port 
latency table and a TCP state latency table, and that selects a lower of said 
1 5 two values. 

35. The modem of Claim 29, further comprising: 

an IP latency resolver that takes input values from an IP sub-protocol 
latency table and an IP TOS field latency table, and that selects a lower of 
20 said two values; and 

a TCP latency resolver that takes input values from a destination port 
latency table and a TCP state latency table, and that selects a lower of said 
two values; 

wherein said IP latency resolver and said TCP latency resolver outputs 
25 are muxed to produce a combined latency value, with said mux being 
controlled by the protocol field within the IP header. 

36. The modem of Claim 29, wherein a latency setting value is provided by 
a PPP latency table, with said value being determined by the PPP protocol 

30 field and the PPP command code field. 
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37. The modem of Claim 36, wherein said PPP latency table value is 
muxed with the muxed value of said IP latency resolver and said TCP latency 
resolver. 

38. The modem of Claim 1 5, wherein said modem comprises: 

a stand alone, embeddable, highly integrated communications product 
that can Internet enable a wide variety of electronic devices. 



39. The modem of Claim 1 5, further comprising: 

a TCP socket filter, wherein only those packets received at said 
modem that are destined for a preconfigured socket connection are allowed 
past said modem; and wherein all other packets are filtered out at by said 
socket filter at the hardware level. 

40. The modem of Claim 1 5, further comprising: 
HTML packet sniffer which parses received HTML data. 



an 



41, 



The modem of Claim 40, wherein said HTML packet sniffer further 



comprises: 

0 . a preset rating that is applied to a packet to determine if said packet is 
to be placed in a received packet buffer. 

42! The modem of Claim 40, wherein said HTML packet sniffer further 
comprises: 

5 an HTTP response parser that takes received packets from a socket, 

and that interprets an HTTP header to determine if data therein contains valid 
■ HTML data and . if so. that enables an HTML rating decoder, which begins to 
parse said HTML data for rating tags. 

0 43. The modem of Claim'40, wherein said HTML packet sniffer fufther 

comprises: ■ . 

an HTML decoder that writes all received data to a received packet 

buffer, and at the same time parses tags; 

wherein, if said HTML decoder detects a rating tag. it compares a 
5 corresponding page's rating to a preset rating level; 
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Wherein, if said page passes, then said page continues to be stored in 
a receive buffer; 

wherein if said page fails, then all further data are suppressed and a 
reject nnessage is stored in memory; and 
5 wherein if said page contains no ratings at a head of said page, said 

modem can be configured to either pass the page or reject said page based 
upon a user configuration. 

44. A modem, comprising: 

1 0 a modem core; and 

a network stack embedded in hardware which executes network 
protocols to allow said modem to communicate on an electronic network, 
wherein said network stack comprises an Internet network protocol stack, 
wherein said network stack sends and receives blocks of data, wherein 

1 5 network protocols that are implemented in said network stack include any of 
the protocols required by PPP, IP, TCP. and UDP communications layers, 
wherein said network stack supports direct memory access (DMA) operations 
to optimize CPU overhead required for data transfers. 

20 45. A method for producing a modem, comprising the steps of: 
providing a modem core; and 

embedding a network stack in hardware, said network stack executing 
network protocols to allow said modem to communicate on an electronic 
network. 

. 25 

46. The method of Claim 45, wherein said network stack comprises an 
internet network protocol stack, wherein said network stack sends and 
receives blocks of data, wherein network protocols that are implemented in 
-■ said network stack include any of the protocols required by PPP, IP. TCP, and 
30 UDP communications layers, wherein said network stack supports direct 
memory access (DMA) operations to optimize CPU overhead required for 
data transfers. 
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The method of Claim 45, further comprising the step of: 
performing IP and TCP packet snooping. 



10 



43 The method of Claim 45. further comprising the step of: 

using a TOS field in an IP header to determine the amount of latency 
used in the transmission of a packet. 

49 The method of Claim 45, further comprising the step of: 

performing latency optimization by checking a TCP header. 

50. The method of claim 45, wherein ail protocol negotiations are kept local 
to said modem by said network stack. 

A nf riaim 45 wherein said network stack 
£^1 The method of uiaim ^=>, 

, . J,, cooUot r.onnection 
1 5 disregards any packet received unless there ,s alre».y » 

set up for it. 

52 The method of Claim 45, further comprising the step of; 

providing a packet sniffer for decoding HTML rating tags, where. sa,d 
20 packet sniffer oniy passes those pages that are within a preset rating ievei. 

53 The method of Claim 52, wherein said packet sniffer is configured 
allow said unrated pages to be passed. 

" 54, The method of Claim 52, wherein a rating level can be programmed 

only via hard wired settings. 

55 The method of Claim 45, Wherein software appncations communicate 
30 with said modem core and said network stack via a socket API. 



wo 99/65219 



PCT/US99/13184 




FIG. 1 

(PRIOR ART) 





Tel. Line^ 


-29 










modem 


core 










Input fifo 


output fifo 




1 


t 






serial port interface 




i 






, 

So f tware . Netwo ri< Stock i 



I 



21 



Web Browser 



-20 



r 



18 



Modem Card 



-19 

-Software' Layer; 



wo 99/65219 



PCTAJS99/13184 



37 



Telephone Line 



Modem Core 



35 



Input 
FIFO 



■33 



-32 



Output 
FIFO 



30 



TCP/UDP/IP/PPP 
(Network Stack) 



■36 



Packet 
Buffer 






Security 
Layer 







34 





Packet 


i Internet ready 




Analyzer 


i Modem Card 



38 



Packet Interface 



-31 



Computer Bus 



-28 



CPU 



-23 



-21 



19a 



Web Browser 



Software Layer 



FIQ. 3 



wo 99/65219 



PCT/US99/13184 



44- 



3/8 



0) 

o 
5 



o 

t/0 



Application 



Socket API 



FIG. 4 



■42 



■43 




IP Packets 









PPP 

Protocol 









-50 



Ser-ia-UDota 



FIG. 5 



wo 99/65219 



PCTAJS99/13184 



4/8 



CO 





CL 








o 


c 




o 












o 






G- 




O 


CL 




< 


- 








CL 




Q 




3 



CJ 
CD 















CD 




Q- 




C 
k. 




O 




he I 
















LxJ 
























u- 




(D 




Q- 




XJ 




D- 




o 








:2 





0) 

c 

05 
03 



03 
O 

c 

D 

x: 
c 

03 

O) 
O 



05 
O 

c 

D 
SI 

c 

05 



c 
o 

05 
00 



o 

CD 

CL 
CL 

a. 

















o 




c 






o 












o 


CL 




CJ 


o 










"q- 






Ol 






<: 








Q_ 

























03 


< 


\CL 






03 


03 O 


sz 






\- 


UJ 


o 




03 
> 

Q 

]a 

03 
00 





c 
o 

o 

03 



03 

D 
03 



a. 





o 








O 




Q- 




CL 




CL 




C 




O 




•— 








05 




00 




o 








o 




Q 




-a 




E 




o 




o 




o 




o 








o 








CL. 




"o 
















o 




C3 












< 




cn 











03 

03 CD 

O tn 

-4-' 

03 c 

cn n5 
o 

cn — 

03 



wo 99/65219 



PCT/US99/13184 



5/8 



0) 

o 
u 




03 




wo 99/65219 



6/8 



PCT/OS99/13184 




wo 99/65219 



PCTAJS99/13184 



7/fi 



03 

u 
a 

a.- 




wo 99/65219 



PCT/US99/13184 



f 

To CPU 



22 



r 



141 



Socket 
(with Dest. Port=aO) 



r 



139 



TCP Engine 



Received Packet 



/3fi 



5/fi 



HTML Packet 
Sniffer 



f 



146 



Received 
Packet 
Buffer 



^144 

Preset Rating 
146-^ 

FIG, 13 



141-^^ 

From— 
Socket 



HTTP Response 
• Parser 



146 



Preset Rating 



142 



HTML Rating 
Decoder 




To Received 
Packet Buffer 



FIG. 14 



KT/US 99/13184 



n,r.n..n.,n,l»n. ocxrUMENTSC ONSIDfeHHO TO BE RELEVANT 

CegcV - Ci.a..on o. Cccurn.m. w.n indcafoawna ,. apprcpna.e. o, rne re.evant passacas 



WO Q5 14356 A (QUALCOMM INC) 
26 May 1995 (1995-05-26) 



figures 1-3 , ■, • « , 

page 5, line 10 -page^, line 2 

PRESTON D J: "INTERNET PROTOCOLS MIGRATE 
TO SILICON FOR NETWORKING DEVICES- 
ELECTRONIC DESIGN, 
vol . 45 , no. 8, 

14 April 1997 (1997-04-14), pages 87-90, 
92-94, XP000730016 
ISSN: 0013-4872 

page 87, left-hand column, paragraph 1 
-page 88, left-hand column, paragraph 2 
page 90, right-hand column, paragraph 3 
-page 91, right-hand column, paragraph 3 

FLOYD S ET AL: "LINK-SHARING AND RESOURCE 
MANAGEMENT MODELS FOR PACKET NETWORKS" 
IEEE /ACM TRANSACTIONS ON NETWORKING, 
II? 3. no. 4 1 August 1995 (1995-08-01), 
pages 365-386, XP000520857 

ISSN: 1063-6692 
page 367 -page 368 

HTRHIAND H J- "Historical Bits i Bytes" 
0§?ufERS & SECURITY INTERNATIONAL JOURNAL 
DEVOTED TO THE STUDY OF TECHNICAL AND 
FINANCIAL ASPECTS OF COMPUTER SECURITY, 

rlaniary''?997'(1997-01-01), page 387-411 
XP004096186 

ISSN: 0167-4048 . , 

oaae 392, left-hand column, paragraph 
-page 396, left-hand column, paragraph o 



"The limits of Web metadata, 



MARCHIORI M: 

WMPUTEr"nETWORKS AND. ISDN SYSTEMS, 
vol. 30, no. 1-7, 

1 April 1998 (1998-04-01), page 1-9 
XP004121445 

ISSN: 0169-7552 
oaqe 7, left-hand column, paragraph 4 
-page 8. left-hand column, paragraph 3 
page 1,' left-hand column, paragraph 1 
-page 2 right-hand column, paragraph 3 



I Relevant to claim No. 

1-4. 
14-16, 
38,45, 
50,55 



1-4, 
14-16, 
38,45, 
50,55 



6-8, 

17-37, 

47-49 



10,39,51 



11-13, 
40-43, 
52-54 



Patent document 
cited in search report 



WO 9514356 



Publication 
date 

25-05-1995 



Patent family 
rnember(s) 



us 


5479475 A 


AU 


683706 B 


AU 


1055895 A 


BR 


9405750 A 


CN 


1115481 A 


EP 


0679323 A 


FI 


953418 A 


JP 


8505995 T 


US 


5761204 A 



date 



26-12 
20-11- 

06- 06- 
05-12- 

07- 02- 
02-11- 
12-07 
25-06 
02-06 



•1995 
■1997 
•1995 
•1995 
■1996 
-1995 
-1995 
-1996 
-1998 



F-.r/US 99/13184 



A. CLASSIFICATION OF SUBJECT MATTER . 

IPC 5 H04M11/05 H04L29/06 

According to International Palsnt Classification (IPC) or to both national classification and IPC 



B. FIELDS SEA RCHED . 

Minbnum documematicn saarchad (classification system loUowad By caasrfication symDols) 

IPC 6 H04M H04L G06F 



Cc=un,an.aUon saarcnod other than minimum docu,.e n.ation to tne extent that sue. documents ara inclucoo -n tne llelcs saarcneo 



- Electronic data base c=nsu«ed during tne interna tional search (name of data base ar-d. where practical, search terms used, 



C. DOCUIVIENTS CONSIDEHED TO BE RELEVANT 



Catsgo^ * Citation of document, with indication, where appropriate, of the relevant passages 



PORTABLE COMPUTER AND COMMUNICATIONS 
ASSOCIATION - MODEM STANDARDS COMMITiEE: 
"The IP Modem Interface Standard" 
PCCA DRAFT, 'Online! 
5 June 1998 (1998-06-05), XP002120914 
Retrieved from the Internet: 
<URL : ftp : //ftp . wrq . com/pcca/i pmdOBOo . pdT> 
'retrieved on 1999-10-08! 
figure 4 

page 9, line 3 -page 15, line 21 



1-4,9, 
14-16, 
38,45, 
50,55 



page 17, line 20 - line 28 



-/-- 



5,44,46 



Further 



cocuments ara listed in the continuation ofbox C. 



Patent family rrsmcars are listed in annex. 



' Special categones of cited documems : 

-A" dccument defining the general state of me art which is net 

considered to De of particular relevance 
-E' earlier document but published on Of after the internaticna! 

filing date 

T- document which may throw doubts on priority claim(9) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

-0- document refemng to an oral disclosure, use. exhibition or 
other means 

-P- document published prior to the international filing date but 
later than the priority date claimed 



lAtsr document puolisnec after the international filing date 
Tpfo^^l^nc net conflict wrth the appl.c^uon bm 

cited to understano ir-e onncioie or theory undahying the 

invention 

document of particular ratevance: tne claimed invention 
clnrK)rba consicarec r.:vel or cannot be considered to 
involve an inventive stao when the document is taken aione 
document of particular relevance; the claimed invention 
'can^irbe considerea to involve an inventive ^^^^^^^ 
document is combinec with one or ^^'^ ^^^^^'J^^'\ f^,'^^ 
mentsrsuah com&inai)on-oeing ocvicus to a person skilled 

in the art. 

document member of :ne same patent family 




29 October 1999 



Name and mailing address of the ISA 

European Patent Oftlce. P.B. 5818 Patentlaan 2 
NL - 2230 HV Rijswijk 
Tai /*.'5i-7n\ n4n-?n40. Tx. 31 551 eoo nt. 



